Post not yet marked as solved
The reason it goes away is that Apple now makes CKRecord conform to Sendable https://developer.apple.com/documentation/cloudkit/ckrecord?changes=latest_minor
Post not yet marked as solved
You can just combine these two predicates in the predicate builder. Assuming your compound1 looks like myEntity.field1 == true and compound2 looks like myEntity.field2 == false you can write
#Predicate { myEntity in
myEntity.field1 == true || myEntity.field2 == false
}
for an AND variant you can do
#Predicate { myEntity in
myEntity.field1 == true && myEntity.field2 == false
}
Post not yet marked as solved
As others have said, it's probably a good idea to have your own unique id (UUID is probably the easiest way). I believe the core data PersistentIdentifier.ID may only be unique to the record on the current install of the current device. If you're doing syncing and want to reference a record on another device, it might not return the same PersistentIdentifier.ID.
Post not yet marked as solved
I've played around with this, trying a lot of solutions, but I might have found a way to do case insensitive compare. In the SwiftData SampleTrips sample project I changed
let filteredList = try? trip.bucketList.filter(#Predicate { item in
item.title.contains(searchText) && tripName == item.trip?.name
})
to:
let filteredList = try? trip.bucketList.filter(#Predicate { item in
return item.title.localizedLowercase.contains(searchText.localizedLowercase) && tripName == item.trip?.name
})
This seemed to work. It seems the macro has support for localizedLowercase but not for lowerCased()
Hope that helps. I'm a lot more excited about SwiftData now.
Post not yet marked as solved
I think you want to change @Binding to @Bindable
from:
struct ListView: View {
@Binding var listDataArray: [DataType]
}
to:
struct ListView: View {
@Bindable var listDataArray: [DataType]
}
I worry that you might have unexpected consequences to add the @Bindable in the body
Post not yet marked as solved
Do the query and data case match? It doesn’t currently support case insensitive queries. A major oversight on their part. I filed a bug and you should too if this is your issue. If the issue is the relationship, you should file that too.
Post not yet marked as solved
I ran into this too. I tried a few different ways that didn't work. Using combine to observe the values didn't work, but I did some digging and found something that might be viable, although it's a little convoluted.
So @Observable is not just making something conform to ObservableObject, it's its own thing, it's writing some of your code for you. So if you expand the macro (right click on @Observable) it will expand the code it's augmenting your code with. You'll see a bunch of @ObservationTracked macros revealed for your properties. There's some other stuff too, but not specific to your property.
@ObservationTracked
var test: String = ""
...
@ObservationIgnored private var _test: String
If you expand that macro you now see the getter and setter for your property:
@ObservationTracked
var test: String = ""
{
get {
access(keyPath: \.test)
return _test
}
set {
withMutation(keyPath: \.test) {
_test = newValue
}
}
}
...
@ObservationIgnored private var _test: String
Now you have hooks into setting the new value. So you can do something like this:
@ObservationIgnored #Flip this to ignored because you're doing your own manual getter/setter#
var test: String {
get {
access(keyPath: \.test)
return _test
}
set {
withMutation(keyPath: \.test) {
_test = newValue
#do your cool thing here#
}
}
}
...
@ObservationIgnored private var _test: String = "" #don't forget to move your initial value here#
So with very light testing this seemed to work as expected. YMMV. I think we'll just have to see if this is a pattern, or if Apple can provide us a way to annotate properties we want a didSet hook for. Either way this might be the exact kind of use case we could write our own macro for. But I'd prefer if Apple solves this. I'm going to file a bug with Apple immediately to request they give us a built in solution. If we want to get it fixed, I think Apple needs to hear about and very soon so it still has a chance in getting in this year.
Post not yet marked as solved
Fixed!
Double check the capitalization of your project path vs your folder capitalization. When mine were mismatched (e.g. /Users/username/Git/Path/To/Project/Project.xcodeproj with a folder path of /Users/username/git/path/to/project/project.xcodeproj) I had this problem. Once I updated them to match the capitalization It worked.
In Xcode select the project (first item in navigation list), show the file inspector and look at where it says Full Path, then compare to your folder structure in Finder
Post not yet marked as solved
Just so this gets bubbled up more this answer colink (Apple wouldn't let me post a direct link ) about mid-way through the comments solved it for me. The tldr; is double check that the groups in your Xcode project have the same capitalization as the folders on disk. Mine had a discrepancy between the root folder name capitalization. Now my errors reliably show. Thank you colink
Post not yet marked as solved
Experiencing the same on Xcode 14.2
Post not yet marked as solved
Still seeing in Xcode 14.0.1
This is happening to me too, I was hoping this post would help me out. I've been suffering from this for several days, so not resolving for me.
One thing I'm curious about, are you using a Watch App + Extension (old style) or just a Watch App?
Apple's example code is still using the old style and works perfectly. For me, the watch can send messages to the phone, but the reply never comes back to the watch.
I'm having the same issue, I've tried both on Monterey and Big Sur. I think we'll need to wait for an update of Xcode.
Update 2: Deleting cache only worked temporarily after removing adding devices. I'm giving up, I think we'll need to wait for Apple to solve.
Update 1: I attempted to delete any Xcode (e.g. com.apple.dt.Xcode) folders/files in the caches folder ~/Library/Caches. I can build again to my watch, for now
Same here. It briefly worked shutting down both phone and watch, removing the phone from the list of paired devices, removing my ADC account and then re-adding, booting everything up. I was able to debug on the watch, then something happened and it went back to being broken. I haven't bothered again since then.
Post not yet marked as solved
Not sure what the purpose of passing in all the items into each sub view. I’m not able to reproduce your crash in a playground, but i was getting a lot of calls to sub views when adding an item because you’re passing in the items as a binding. I removed the binding from the SubView and only passed in the number for each SubView. That stopped the Subviews from updating when adding items:
import SwiftUI
import PlaygroundSupport
import SwiftUI
struct ContentView: View {
var body: some View {
TestView(items: [1, 2, 3, 4, 5])
}
}
struct TestView: View {
@State var items: [Int]
var body: some View {
NavigationView {
VStack {
Text("Hello")
List {
ForEach(items, id: \.self) { item in
NavigationLink(destination: SubView(number: item)) {
Text("\(item)")
}
}
}
Button(action: {
self.items.append(self.items.count + 1)
}) {
Text("Add")
}
}
}
}
}
struct SubView: View {
var number: Int
var body: some View {
Group {
Print("\(number)")
Text("\(number)")
}
}
}
extension View {
func Print(_ items: Any..., separator: String = " ", terminator: String = "\n") -> some View {
let output = items.map { "\($0)" }.joined(separator: separator)
Swift.print("→ " + output, terminator: terminator)
return EmptyView()
}
}
PlaygroundPage.current.setLiveView(ContentView())
I think it might be that you’re doing something that holds on to the reference of the items longer than you should or. You might try two things.
If possible, don’t pass in those items and remove the binding in the Subview
If that is needed for some reason further down look at any blocks you have where you might be creating a retain cycle that would keep those subviews alive longer than they should. Look up retain cycles in blocks for help, also look in to weak vs strong references. You might have some objects that point to each and never get released.
good luck
